@martin-frbg @Mousius can you please have a look?

Thanks for looking into this - though I'm not immediately convinced that the speedup warrants the added complexity @Mousius ? At least I'd like to put this off until after the 0.3.31 release.

Thanks for looking into this - though I'm not immediately convinced that the speedup warrants the added complexity @Mousius ? At least I'd like to put this off until after the 0.3.31 release.

The speedup is one thing, the other is enabling GEMM kernels without the need to also implement the other kernels. This would enable us to land existing SME kernels, as previously proposed here: #5011 (comment)

Putting off until after 0.3.31 makes perfect sense to me as it's a relatively high risk change.

Thanks for looking into this - though I'm not immediately convinced that the speedup warrants the added complexity @Mousius ? At least I'd like to put this off until after the 0.3.31 release.

Hi Martin. Thanks for taking a look. I'm happy for this to go in after the release. Do you have a rough estimate for when that might be, so I can share internally?

@martin-frbg congrats on getting the release out. Would it be possible to get this merged?

I'm probably missing something obvious, but I'm still a bit confused why this needs the addition of "COMM" kernels instead of declaring dedicated ?TRMM and ?SYMM COPY kernels within the existing framework, like the riscv64 folks do in e.g. KERNEL.RISCV64_ZVL128B ?

I'm probably missing something obvious, but I'm still a bit confused why this needs the addition of "COMM" kernels instead of declaring dedicated ?TRMM and ?SYMM COPY kernels within the existing framework, like the riscv64 folks do in e.g. KERNEL.RISCV64_ZVL128B ?

The intent is to capture what is still common between trmm and symm, and reduce duplicate code. I can refactor if preferred? @Mousius let me know if you have opinions either way. No preference on my part.

I agree with @martin-frbg, it'd be better to name them aligned with the algorithms they're influencing.

@martin-frbg we're targeting these types of blocks:

I think that'd be adding SYMM_ONCOPY/TRMM_ONCOPY to replace GEMM_ONCOPY if we override it, else falling back to the GEMM_ONCOPY?

Yes, at least that's my current understanding - that mapping ?SYMM_ONCOPY et al in the KERNEL file should do. I haven't tried it though, as my lowly M4 doesn't handle the SVE bits - guess I'd need to look into hijacking our Numpy-sponsored AWS CI job to run on M9g ?

I don't think we currently have ?SYMM_ONCOPY, the RISCV kernels replace the triangle copies along M:

Which was originally done for SVE:

So we're aware of these ones being overridable, but the GEMM_ONCOPY doesn't have an override as yet.

For a sanity check, I couldn't find any reference to SYMM_ONCOPY:

• SYMM_ONCOPY / SYMMONCOPY / SSYMM_ONCOPY / SSYMMONCOPY